查看原文
其他

一位程序媛妹妹的半年成长总结

辣椒炒肉 码农翻身 2021-04-20
本文来自“辣椒炒肉”的投稿,她是一个前端程序媛,毕业半年成长很大,她的经验总结非常值得职场新人借鉴。


先自我介绍一下,我是前端程序媛妹妹,应届生,2019 年 7 月份入职到 2020 年 1 月已经工作半年,这半年里自己以肉眼可见的速度成长,写写这半年的经历,回顾总结一下,希望我的经历能给你带来不一样的“鸡汤”。 


入职的每个应届生会分配一个导师,工作内容大致和导师方向一致。刚入职的一个月,主要就是熟悉公司的一些基础建设、用什么技术栈、跟导师一起开需求评审会、改改小 bug、调调样式或增加小功能。


最开始的工作比较轻松,没有具体工作的时候我就结合系统功能和代码,梳理系统逻辑,绘制脑图。这件事还是很有用的,对我后来快速定位 bug、迭代小功能起了关键性的作用。 



第一次独立做一个完整的需求 



第一次做一个完整的需求是入职两个月的时候,当时还是挺慌的,感觉自己还没有摸清门路就要开始一个人做事了,而且还是一个倒排期的移动端需求,这无疑又为我添加了一份紧张感。


每天根据需求文档疯狂写代码,天天压力大到梦里都在写代码、解 bug,早上七点钟自然醒,最担心的事情就是功能实现不完。


就在这时导师很忙,完全只能靠自己,遇到什么技术难题,都要自己来解,我迎来了前所未有的恐慌。 


尽管后来功能上线了,但依然很虚,时刻都在担心线上会不会有 bug。每天会不定时打开公司的APP几次,实际操作一下自己上线的功能,验一验有没有什么bug ;同时关注产研群,看是否有 bug 反馈。


过了大概 2 周的时间,功能在线上很稳定,没有任何 bug 反馈,这才放心下来。


由此我对自己的技术水平也有了新的认识,实际上并没有自己想的那么差。压力最大、问题最多的时候也是成长最快的时候,做完整个需求以后,前后端怎么配合、什么时间节点该做什么事,需求从评审到上线的链路也渐渐清晰了。 



面对压力 



做这个需求的时候我感觉到了非常大的压力,感觉每天自己就是一个高压锅。对压力的思考,也正是这个需求给我带来最大的成长。 


压力来源于什么?压力来源于自己认为自己的能力不足以 hold 住整个事。因为自己没有做过,面对未知的恐惧人就会不自觉产生压力。有什么好办法面对压力吗?


正视、面对、突破。


1. 首先不能给自己增加压力的砝码,切记不要思考是不是自己能力不行,我怎么这么菜。越是思考负面情绪因素,越让自己头脑不清晰,压力越大自己越紧绷,这时候如果出现一点额外的差错,就感觉天要塌了,越是压力大越容易出差错。


2. 有压力的时候,也就是成长最快的时候。按部就班处理每天遇到的难题,不会什么就学什么,不要担心它、也不要因此而焦虑,把该做好的事情做好,当做好之后压力也就解除了,同时自己也成长了。


3. 做事情的时候要给自己信心,不断地给自己加油打气,抗一抗,努努力加把劲就过去了。当下次同样难度的事情到来时,已经经历过一次便不会紧张焦虑。想想看,能力是不是这样增长起来的呢? 



换业务方向 



在工作差不多两个月的时候,整个前端大组计划根据业务方向划分成 4 个小组,我现在的工作属于 A 组,趁这个时期,我想要在划分方向前调整到 B 组去。 


为什么要换到 B 组? 


简单说说 A 组。A 组的业务,由于因为历史项目较难维护困难,作为新人的我很头疼,我每新增一点功能都感到紧张,毕竟线上无小事。 


再说说B组。1. B 组同学经常做 code review,基本上每周都会看到他们 code review 的会邀,作为新人我对 CR 这件事还是很向往的;B 组业务复杂、系统功能多,但是却有一套规范,多人写的代码十分接近像一个人写出来的。


2. B 组同学的能力成梯队,有资深的老员工负责一个项目,带着几个同学一起做,看他们平时工作很 happy。 


我有了初步的想法后,直接找到 B 组的 leader,先了解下 B 组有关的业务。听听这组的老大怎么说。(下文 B 组 leader 直接简称老大) 


让我非常意外的是,约到了 B 组 leader 后,他在会议室非常认真地给我讲了一个多小时,还写了板书,把多个业务之间的关系讲得明明白白;


不仅介绍了 B 组当前做的事,还介绍了未来的规划,规划包括了业务需要和技术驱动。


我和 B 组 leader 在此之前没有任何交集,但是就冲这认真程度,我已经决定来 B 组了,我仿佛已经看到了未来的光明,哈哈。


我和 B 组的 leader 表达了我想来 B 组的意愿,他表示欢迎。接下来就是和大组的 leader 沟通了,在此次沟通之前,我认为这是一件很难的事,因为我担心:


如果 A 组人力不足不允许我去 B 组怎么办? B 组真的需要我吗?大组 leader 会不会觉得我这刚工作两个月的新同学,想法有点多啊?


认真地准备了自己的说辞,带着诸多疑点,和大组 leader 沟通了一次。 


没有想到,结果如我所愿!大组 leader 不仅同意了,而且还非常高兴我能主动表达自己的想法。 



主动反馈 



事后总结了一下,主动反馈在职场中非常重要。主动可以改变你看似不能改变的事实,主动反馈也是站在别人的角度去考虑问题


你的上级大概率不会了解每一个人,如果你能主动 push 消息给你的上级,和上级有一个良性的互动,那么他越了解你、越了解你手上的工作,也就越能帮助你,一旦你出了什么岔子或者有什么疑惑,他能切中要害给你解答。


除了和你的上级反馈,也要与自己合作的产品、任何角色的开发、运营同学等及时反馈,有消息及时反馈给对方,在对方的心里你更靠谱。


反馈什么样的问题呢?我大致分了几类:


1. 可能延期上线的风险 

2. 自己近期的工作进展和疑问 

3. 对团队建设的想法 

4. 发生变化、会影响结果的消息。 



独挡一面的时刻 



由于 B 组业务多,人力不足,刚来一个月,老大直接扔给我了一个 P0(项目优先级的排序方法:P0、P1……)的项目,我一个人负责。


我特别兴奋,自从独立做了一个完整需求以后,自己信心大增,发现自己是有能力独自完成一个需求的,而且技术能力也没有自认为的那么差,有了上次的积累,我相信自己这次会做得更好。


这次是我第一次独自负责一个项目,检验自己能力和展示自己能力的时刻到了。 


从零开始一个项目,遇到的挑战还是很多的。平时只是在原有项目上迭代功能,现在从建仓库、申请域名、搭建测试环境、申请上线机器等一系列事情开始,写代码只是其中一个环节了。 


每天赶着做赶着做,还是遇到了一个大风险,距离上线还有两天,有一个关键的功能没有实现。


这时候我已经完全没有了办法,心里甚至有点崩溃,归因于自己能力不足导致没有开发完成,只能去问老大现在该怎么办。


老大和产品沟通,结论是没做的功能后续再迭代,问题解决了。  


这件事让我非常震惊!


因为在我的心里认为已经走投无路,这该怎么处理呢?老大和产品的沟通过程我是全程在的,我发现老大是知道这个风险的,时间紧很可能完不成,每天站会的时候产品也在,他提前和业务方沟通过,在约定的时间点不一定会完成全部功能,业务方也给出了最小可用版本的要求。


原来业务方的要求并不是一成不变的,他们在开发前期也是了解到时间紧的,在摆明了客观条件下出现问题,他们也会给出一些让步,并不是咬得死死的要上线全部功能。 


在这次需求完成后,有了很多新的认识,大致分为以下几个方面。 



态度 



永远采取对解决问题最有利的态度。      


开发过程中可能会出现预料不到的状况,当问题出现的时候,首先要摆正的就是自己的态度,不甩锅、不带情绪,采取对解决问题最有利的态度,缺少什么资源、产品有什么问题、接口哪里不合理就及时和对方沟通解决,以最短时间解决出现的问题。 



对需求的思考 



在做本次需求之前,很少思考为什么做这个需求。这个产品设计的合理吗?在需求评审的时候大脑也不够活跃,很少提出问题,通常是拿过来设计稿直接做,做完了上线。


但是这一次情况完全不同,我不假思索去做这个需求,结果就给自己留下了坑,在做的过程中才发现有问题,在开发中去改的成本远大于开发前想好。 


这一次非常深刻提醒了我,开发前要主动思考需求,甚至说在某些时候细节的考虑要做得比产品还充分,做之前和产品充分交流,随时提出问题,解决问题,开发前是万万不能少了思考的,要培养自己产品思维。 


对于需求的思考和几位前辈交流过,结合前辈给出的建议我给自己提出了开发前 5 问


每次在拿到需求的时候我会问自己以下几个问题,思考并尝试回答,如果回答不清楚就问产品或者其他前辈。 


1.首先了解为什么要做这个需求,它的背景是什么,能带来多大的价值?  


2.这个功能在当前的系统是否已经实现了?如果实现了,是否可以复用,如果不能复用,差别在哪里? 


3.这个功能除了满足当前的需求,还可以举一反三用到别处吗,是否可以抽出公用业务组件? 


4.这个需求是一次性的需求还是长期的,后期会怎么发展? 


5.技术上实现的成本高不高,如果高的话,是不是可以选最痛的、优先级最高的做,然后小步迭代? 



提前暴露风险 


有问题、不能如期上线要提前报给上级。


提前是一个什么样的时机呢?暴露风险最好的时机是每天站会,如果没有站会,就及时和上级说明情况,让他提前知晓,而不是上线前才让他知道。提前暴露风险就是在为自己争取时间,暴露风险后可能的解决方案是延期上线、或者上线一部分功能。最初我很怕暴露风险,怕上级认为我能力不行,其实这都是以自己的角度思考问题,风险的成因是多方面的,自己的能力只是其中一个。 



了解业务 



曾经很不理解老刘在公众号提出的了解业务,也不明白自己的上级、部门 boss 经常提醒大家去了解业务,现在我有一点点感受了。


了解业务所涉及的名词、流程、相关的功能、各业务之间的关系,可以使自己在开发过程中更加游刃有余,预测可能出现的问题,产品遗漏的逻辑分支,争取做一个信息量最全的人。


在业务上常问自己,这是什么?这个业务的背景是什么?有什么价值?尝试落实到纸面上,如果写不清楚就继续了解、去问,直到写明白。


这是目前我认为了解业务比较好的一个方式,问了解它的人,他也乐于给你讲清楚相关信息。 



写在最后



我发现,对于刚工作的小白来说,在工作中学习是最快的方式。每做一个需求,都会碰到一些技术难题,边学习边解决问题,能力嗖嗖嗖地就上来了,技术成长的速度远远超过自己周末默默啃源码、看书本。


这半年是收获颇丰的半年,自己成长了很多,由衷感谢这半年来帮助过我、给我解答诸多疑问的前辈。


2020 会面对更多的挑战,加油~


欢迎向码农翻身公众号投稿,稿酬丰厚!能用故事讲解技术,稿费1000元,讲述职场经验、个人成长稿费700元。详情参见《可能是全网最高稿酬,速来!


往期精彩回顾



我是一个线程

我是一个Java Class

面向对象圣经

函数式编程圣经

TCP/IP之大明邮差

CPU阿甘

我是一个网卡

我是一个路由器

一个故事讲完HTTPs

编程语言的巅峰

Java:一个帝国的诞生

JavaScript:一个屌丝的逆袭

负载均衡的原理

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存